65. Gitlab CI
上节课我们使用 Helm 快速的将 Gitlab 安装到了我们的 Kubernetes 集群中，这节课来和大家介绍如何使用 Gitlab CI 来做持续集成。
简介
从 Gitlab 8.0 开始，Gitlab CI 就已经集成在 Gitlab 中，我们只要在项目中添加一个.gitlab-ci.yml文件，然后添加一个Runner，即可进行持续集成。在介绍 Gitlab CI 之前，我们先看看一些 Gitlab CI 的一些相关概念。
Pipeline
一次 Pipeline 其实相当于一次构建任务，里面可以包含很多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发 Pipeline 构建，如下图所示：
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages
Stages 表示一个构建阶段，也就是上面提到的一个流程。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：
- 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
- 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
- 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败
Stages 和 Pipeline 的关系如下所示：
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Jobs
Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
- 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败
Jobs 和 Stage 的关系如下所示：
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
Gitlab Runner
如果理解了上面的基本概念之后，可能我们就会发现一个问题，我们的构建任务在什么地方来执行呢，以前用 Jenkins 在 Master 和 Slave 节点都可以用来运行构建任务，而来执行我们的 Gitlab CI 构建任务的就是 Gitlab Runner。
我们知道大多数情况下构建任务都是会占用大量的系统资源的，如果直接让 Gitlab 本身来运行构建任务的话，显然 Gitlab 的性能会大幅度下降的。GitLab CI 最大的作用是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情交给一个独立的 Gitlab Runner 来做就会好很多，更重要的是 Gitlab Runner 可以安装到不同的机器上，甚至是我们本机，这样完全就不会影响到 Gitlab 本身了。
安装
安装 Gitlab Runner 非常简单，我们可以完全安装官方文档：https://docs.gitlab.com/runner/install/即可，比如可以直接使用二进制、Docker 等来安装。同样的，我们这里还是将 Gitlab Runner 安装到 Kubernetes 集群中来，让我们的集群来统一管理 Gitlab 相关的服务。
1.验证 Kubernetes 集群
执行下面的命令验证 Kubernetes 集群：
$ kubectl cluster-info
Kubernetes master is running at https://10.151.30.11:6443
KubeDNS is running at https://10.151.30.11:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
cluster-info这个命令会显示当前链接的集群状态和可用的集群服务列表。
2.获取 Gitlab CI Register Token
前面的章节中我们已经成功安装了 Gitlab，在浏览器中打开git.qikqiak.com页面，然后登录后进入到管理页面http://git.qikqiak.com/admin，然后点击导航栏中的Runner，可以看到该页面中有两个总要的参数，一个是 URL，另外一个就是 Register Token，下面的步骤中需要用到这两个参数值。
注意：不要随便泄露 Token
3.编写 Gitlab CI Runner 资源清单文件
同样我们将 Runner 相关的资源对象都安装到kube-ops这个 namespace 下面，首先，我们通过 ConfigMap 资源来传递 Runner 镜像所需的环境变量（runner-cm.yaml）:
apiVersion: v1
data:
REGISTER_NON_INTERACTIVE: "true"
REGISTER_LOCKED: "false"
METRICS_SERVER: "0.0.0.0:9100"
CI_SERVER_URL: "http://gitlab.kube-ops.svc.cluster.local/ci"
RUNNER_REQUEST_CONCURRENCY: "4"
RUNNER_EXECUTOR: "kubernetes"
KUBERNETES_NAMESPACE: "kube-ops"
KUBERNETES_PRIVILEGED: "true"
KUBERNETES_CPU_LIMIT: "1"
KUBERNETES_CPU_REQUEST: "500m"
KUBERNETES_MEMORY_LIMIT: "1Gi"
KUBERNETES_SERVICE_CPU_LIMIT: "1"
KUBERNETES_SERVICE_MEMORY_LIMIT: "1Gi"
KUBERNETES_HELPER_CPU_LIMIT: "500m"
KUBERNETES_HELPER_MEMORY_LIMIT: "100Mi"
KUBERNETES_PULL_POLICY: "if-not-present"
KUBERNETES_TERMINATIONGRACEPERIODSECONDS: "10"
KUBERNETES_POLL_INTERVAL: "5"
KUBERNETES_POLL_TIMEOUT: "360"
kind: ConfigMap
metadata:
labels:
app: gitlab-ci-runner
name: gitlab-ci-runner-cm
namespace: kube-ops
要注意CI_SERVER_URL对应的值需要指向我们的 Gitlab 实例的 URL（可以是外网地址，也可以是 Kubernetes 集群内部的 Service DNS 地址，因为 Runner 也是运行在 Kubernetes 集群中的），并加上/ci（ http://gitlab.kube-ops.svc.cluster.local/ci ）。此外还添加了一些构建容器运行的资源限制，我们可以自己根据需要进行更改即可。
注意：在向 ConfigMap 添加新选项后，需要删除 GitLab CI Runner Pod。因为我们是使用
envFrom来注入上面的这些环境变量而不是直接使用env的（envFrom 通过将环境变量放置到ConfigMaps或Secrets来帮助减小清单文件。
另外如果要添加其他选项的话，我们可以在 Pod 中运行gitlab-ci-multi-runner register --help命令来查看所有可使用的选项，只需为要配置的标志添加 env 变量即可，如下所示：
gitlab-runner@gitlab-ci-runner-0:/$ gitlab-ci-multi-runner register --help
[...]
--kubernetes-cpu-limit value The CPU allocation given to build containers (default: "1") [$KUBERNETES_CPU_LIMIT]
--kubernetes-memory-limit value The amount of memory allocated to build containers (default: "4Gi") [$KUBERNETES_MEMORY_LIMIT]
--kubernetes-service-cpu-limit value The CPU allocation given to build service containers (default: "1") [$KUBERNETES_SERVICE_CPU_LIMIT]
--kubernetes-service-memory-limit value The amount of memory allocated to build service containers (default: "1Gi") [$KUBERNETES_SERVICE_MEMORY_LIMIT]
--kubernetes-helper-cpu-limit value The CPU allocation given to build helper containers (default: "500m") [$KUBERNETES_HELPER_CPU_LIMIT]
--kubernetes-helper-memory-limit value The amount of memory allocated to build helper containers (default: "3Gi") [$KUBERNETES_HELPER_MEMORY_LIMIT]
--kubernetes-cpu-request value The CPU allocation requested for build containers [$KUBERNETES_CPU_REQUEST]
...
--pre-clone-script value Runner-specific command script executed before code is pulled [$RUNNER_PRE_CLONE_SCRIPT]
[...]
如果定义的 Gitlab 域名并不是通过外网的 DNS 进行解析的，而是通过 /etc/hosts 俩进行映射的，那么我们就需要在 runner 的 Pod 中去添加 git.qikqiak.com 对应的 hosts 了，那么如何添加呢？我们可以想到的是 Pod 的 hostAlias 可以实现这个需求，但是 runner 的 Pod 是自动生成的，没办法直接去定义 hostAlias。这里我们就可以通过上面的--pre-clone-script参数来指定一段脚本来添加 hosts 信息，也就是在上面的 ConfigMap 中添加环境变量RUNNER_PRE_CLONE_SCRIPT的值即可：
RUNNER_PRE_CLONE_SCRIPT = "echo 'xx.xx.xxx.xx git.qikqiak.com' >> /etc/hosts"
除了上面的一些环境变量相关的配置外，还需要一个用于注册、运行和取消注册 Gitlab CI Runner 的小脚本。只有当 Pod 正常通过 Kubernetes（TERM信号）终止时，才会触发转轮取消注册。 如果强制终止 Pod（SIGKILL信号），Runner 将不会注销自身。必须手动完成对这种被杀死的 Runner 的清理，配置清单文件如下：（runner-scripts-cm.yaml）
apiVersion: v1
data:
run.sh: |
#!/bin/bash
unregister() {
kill %1
echo "Unregistering runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner unregister -t "$(/usr/bin/gitlab-ci-multi-runner list 2>&1 | tail -n1 | awk '{print $4}' | cut -d'=' -f2)" -n ${RUNNER_NAME}
exit $?
}
trap 'unregister' EXIT HUP INT QUIT PIPE TERM
echo "Registering runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner register -r ${GITLAB_CI_TOKEN}
sed -i 's/^concurrent.*/concurrent = '"${RUNNER_REQUEST_CONCURRENCY}"'/' /home/gitlab-runner/.gitlab-runner/config.toml
echo "Starting runner ${RUNNER_NAME} ..."
/usr/bin/gitlab-ci-multi-runner run -n ${RUNNER_NAME} &
wait
kind: ConfigMap
metadata:
labels:
app: gitlab-ci-runner
name: gitlab-ci-runner-scripts
namespace: kube-ops
我们可以看到需要一个 GITLAB_CI_TOKEN，然后我们用 Gitlab CI runner token 来创建一个 Kubernetes secret 对象。将 token 进行 base64 编码：
$ echo rcVZF-mdHt9qCyyrCDgS | base64 -w0
cmNWWkYtbWRIdDlxQ3l5ckNEZ1MK
base64 命令在大部分 Linux 发行版中都是可用的。
然后使用上面的 token 创建一个 Secret 对象：(gitlab-ci-token-secret.yaml)
apiVersion: v1
kind: Secret
metadata:
name: gitlab-ci-token
namespace: kube-ops
labels:
app: gitlab-ci-runner
data:
GITLAB_CI_TOKEN: cmNWWkYtbWRIdDlxQ3l5ckNEZ1MK
然后接下来我们就可以来编写一个用于真正运行 Runner 的控制器对象，我们这里使用 Statefulset。首先，在开始运行的时候，尝试取消注册所有的同名 Runner，当节点丢失时（即NodeLost事件），这尤其有用。然后再尝试重新注册自己并开始运行。在正常停止 Pod 的时候，Runner 将会运行unregister命令来尝试取消自己，所以 Gitlab 就不能再使用这个 Runner 了，这个是通过 Kubernetes Pod 生命周期中的hooks来完成的。
另外我们通过使用envFrom来指定Secrets和ConfigMaps来用作环境变量，对应的资源清单文件如下：(runner-statefulset.yaml)
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: gitlab-ci-runner
namespace: kube-ops
labels:
app: gitlab-ci-runner
spec:
updateStrategy:
type: RollingUpdate
replicas: 2
serviceName: gitlab-ci-runner
selector:
matchLabels:
app: gitlab-ci-runner
template:
metadata:
labels:
app: gitlab-ci-runner
spec:
volumes:
- name: gitlab-ci-runner-scripts
projected:
sources:
- configMap:
name: gitlab-ci-runner-scripts
items:
- key: run.sh
path: run.sh
mode: 0755
serviceAccountName: gitlab-ci
securityContext:
runAsNonRoot: true
runAsUser: 999
supplementalGroups: [999]
containers:
- image: gitlab/gitlab-runner:latest
name: gitlab-ci-runner
command:
- /scripts/run.sh
envFrom:
- configMapRef:
name: gitlab-ci-runner-cm
- secretRef:
name: gitlab-ci-token
env:
- name: RUNNER_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
ports:
- containerPort: 9100
name: http-metrics
protocol: TCP
volumeMounts:
- name: gitlab-ci-runner-scripts
mountPath: "/scripts"
readOnly: true
restartPolicy: Always
可以看到上面我们使用了一个名为 gitlab-ci 的 serviceAccount，新建一个 rbac 资源清单文件：(runner-rbac.yaml)
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-ci
namespace: kube-ops
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab-ci
namespace: kube-ops
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitlab-ci
namespace: kube-ops
subjects:
- kind: ServiceAccount
name: gitlab-ci
namespace: kube-ops
roleRef:
kind: Role
name: gitlab-ci
apiGroup: rbac.authorization.k8s.io
4.创建 Runner 资源对象
资源清单文件准备好后，我们直接创建上面的资源对象：
$ ls
gitlab-ci-token-secret.yaml runner-cm.yaml runner-rbac.yaml runner-scripts-cm.yaml runner-statefulset.yaml
$ kubectl create -f .
secret "gitlab-ci-token" created
configmap "gitlab-ci-runner-cm" created
serviceaccount "gitlab-ci" created
role.rbac.authorization.k8s.io "gitlab-ci" created
rolebinding.rbac.authorization.k8s.io "gitlab-ci" created
configmap "gitlab-ci-runner-scripts" created
statefulset.apps "gitlab-ci-runner" created
创建完成后，可以通过查看 Pod 状态判断 Runner 是否运行成功：
$ kubectl get pods -n kube-ops
NAME READY STATUS RESTARTS AGE
gitlab-7bff969fbc-k5zl4 1/1 Running 0 4d
gitlab-ci-runner-0 1/1 Running 0 3m
gitlab-ci-runner-1 1/1 Running 0 3m
......
可以看到已经成功运行了两个（具体取决于StatefulSet清单中的副本数) Runner 实例，然后切换到 Gitlab Admin 页面下面的 Runner 页面：
当然我们也可以根据需要更改 Runner 的一些配置，比如添加 tag 标签等。
Gitlab CI
基本配置
接下来使用 Gitlab CI 所用到的代码库可以从 Github 上获得：cnych/presentation-gitlab-k8s，可以在 Gitlab 上新建一个项目导入该仓库，当然也可以新建一个空白的仓库，然后将 Github 上面的项目 Clone 到本地后，更改远程仓库地址即可：
$ git clone https://github.com/cnych/presentation-gitlab-k8s.git
$ cd presentation-gitlab-k8s
# Change the remote of the repository
$ git remote set-url origin ssh://git@git.qikqiak.com:30022/root/presentation-gitlab-k8s.git
# Now to push/"import" the repository run:
$ git push -u origin master
当我们把仓库推送到 Gitlab 以后，应该可以看到 Gitlab CI 开始执行构建任务了:
此时 Runner Pod 所在的 namespace 下面也会出现两个新的 Pod：
$ kubectl get pods -n kube-ops
NAME READY STATUS RESTARTS AGE
gitlab-7bff969fbc-k5zl4 1/1 Running 0 4d
gitlab-ci-runner-0 1/1 Running 0 4m
gitlab-ci-runner-1 1/1 Running 0 4m
runner-9rixsyft-project-2-concurrent-06g5w4 0/2 ContainerCreating 0 4m
runner-9rixsyft-project-2-concurrent-1t74t9 0/2 ContainerCreating 0 4m
......
这两个新的 Pod 就是用来执行具体的 Job 任务的，这里同时出现两个证明第一步是并行执行的两个任务，从上面的 Pipeline 中也可以看到是 test 和 test2 这两个 Job。我们可以看到在执行 image_build 任务的时候出现了错误：
我们可以点击查看这个 Job 失败详细信息：
$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: incorrect username or password
ERROR: Job failed: command terminated with exit code 1
出现上面的错误是因为我们并没有在 Gitlab 中开启 Container Registry，所以环境变量中并没有这些值，还记得前面章节中我们安装的 Harbor 吗？我们这里使用 Harbor 来作为我们的镜像仓库，这里我们只需要把 Harbor 相关的配置以参数的形式配置到环境中就可以了。
定位到项目 -> 设置 -> CI/CD，展开Environment variables栏目，配置镜像仓库相关的参数值：
配置上后，我们在上面失败的 Job 任务上点击“重试”，在重试过后依然可以看到会出现下面的错误信息：
$ docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://registry.qikqiak.com/v2/: x509: certificate signed by unknown authority
ERROR: Job failed: command terminated with exit code 1
从错误信息可以看出这是因为登录私有镜像仓库的时候证书验证错误，因为我们根本就没有提供任何证书，所以肯定会失败的，还记得我们之前在介绍 Harbor 的时候的解决方法吗？第一种是在 Docker 的启动参数中添加上insecure-registries，另外一种是在目录/etc/docker/certs.d/下面添加上私有仓库的 CA 证书，同样，我们只需要在 dind 中添加 insecure 的参数即可：
services:
- name: docker:dind
command: ["--insecure-registry=registry.qikqiak.com"]
其中
registry.qikqiak.com就是我们之前配置的私有镜像仓库地址。
然后保存.gitlab-ci.yml文件，重新提交到代码仓库，可以看到又触发了正常的流水线构建了，在最后的阶段deploy_review仍然可以看到失败了，这是因为在最后的部署阶段我们使用kubectl工具操作集群的时候并没有关联上任何集群。
我们在 Gitlab CI 中部署阶段使用到的镜像是cnych/kubectl，该镜像的Dockerfile文件可以在仓库https://github.com/cnych/docker-kubectl中获取：
FROM alpine:3.8
MAINTAINER cnych <icnych@gmail.com>
ENV KUBE_LATEST_VERSION="v1.13.4"
RUN apk add --update ca-certificates \
&& apk add --update -t deps curl \
&& apk add --update gettext \
&& apk add --update git \
&& curl -L https://storage.googleapis.com/kubernetes-release/release/${KUBE_LATEST_VERSION}/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl \
&& chmod +x /usr/local/bin/kubectl \
&& apk del --purge deps \
&& rm /var/cache/apk/*
ENTRYPOINT ["kubectl"]
CMD ["--help"]
我们知道kubectl在使用的时候默认会读取当前用户目录下面的~/.kube/config文件来链接集群，当然我们可以把连接集群的信息直接内置到上面的这个镜像中去，这样就可以直接操作集群了，但是也有一个不好的地方就是不方便操作，假如要切换一个集群还得重新制作一个镜像。所以一般我们这里直接在 Gitlab 上配置集成 Kubernetes 集群。
在项目页面点击Add Kubernetes Cluster -> Add existing cluster：
1.Kubernetes cluster name 可以随便填
2.API URL 是你的集群的apiserver的地址， 一般可以通过输入kubectl cluster-info获取，Kubernetes master 地址就是需要的
$ kubectl cluster-info
Kubernetes master is running at https://10.151.30.11:6443
KubeDNS is running at https://10.151.30.11:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
3.CA证书、Token、项目命名空间
对于我们这个项目准备部署在一个名为gitlab的 namespace 下面，所以首先我们需要到目标集群中创建一个 namespace:
$ kubectl create ns gitlab
由于我们在部署阶段需要去创建、删除一些资源对象，所以我们也需要对象的 RBAC 权限，这里为了简单，我们直接新建一个 ServiceAccount，绑定上一个cluster-admin的权限：(gitlab-sa.yaml)
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab
namespace: gitlab
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: gitlab
namespace: gitlab
subjects:
- kind: ServiceAccount
name: gitlab
namespace: gitlab
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
然后创建上面的 ServiceAccount 对象：
$ kubectl apply -f sa.yaml
serviceaccount "gitlab" created
clusterrolebinding.rbac.authorization.k8s.io "gitlab" created
可以通过上面创建的 ServiceAccount 获取 CA 证书和 Token：
$ kubectl get serviceaccount gitlab -n gitlab -o json | jq -r '.secrets[0].name'
gitlab-token-f9zp7
# 然后根据上面的Secret找到CA证书
$ kubectl get secret gitlab-token-f9zp7 -n gitlab -o json | jq -r '.data["ca.crt"]' | base64 -d
xxxxxCA证书内容xxxxx
# 当然要找到对应的 Token 也很简单
$ kubectl get secret gitlab-token-f9zp7 -n gitlab -o json | jq -r '.data.token' | base64 -d
xxxxxxtoken值xxxx
填写上面对应的值添加集群：
.gitlab-ci.yml
现在 Gitlab CI 的环境都准备好了，我们可以来看下用于描述 Gitlab CI 的.gitlab-ci.yml文件。
一个 Job 在.gitlab-ci.yml文件中一般如下定义：
# 运行golang测试用例
test:
stage: test
script:
- go test ./...
上面这个 Job 会在 test 这个 Stage 阶段运行。
为了指定运行的 Stage 阶段，可以在.gitlab-ci.yml文件中放置任意一个简单的列表：
# 所有 Stage
stages:
- test
- build
- release
- deploy
你可以指定用于在全局或者每个作业上执行命令的镜像：
# 对于未指定镜像的作业，会使用下面的镜像
image: golang:1.10.3-stretch
# 或者对于特定的job使用指定的镜像
test:
stage: test
image: python:3
script:
- echo Something in the test step in a python:3 image
对于
.gitlab-ci.yml文件的的其他部分，请查看如下文档介绍：https：//docs.gitlab.com/ce/ci/yaml/README.html。
在我们当前的项目中定义了 4 个构建阶段：test、build、release、review、deploy，完整的.gitlab-ci.yml文件如下：
image:
name: golang:1.10.3-stretch
entrypoint: ["/bin/sh", "-c"]
# 为了能够使用go get，需要将代码放在 $GOPATH 中，比如你的 gitlab 域名是 mydomain.com，你的代码仓库是 repos/projectname，默认的 GOPATH 是 /go，然后你就需要将你的代码放置到 GOPATH 下面，/go/src/mydomain.com/repos/projectname，用一个软链接指过来就可以了
before_script:
- mkdir -p "/go/src/git.qikqiak.com/${CI_PROJECT_NAMESPACE}"
- ln -sf "${CI_PROJECT_DIR}" "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}"
- cd "/go/src/git.qikqiak.com/${CI_PROJECT_PATH}/"
stages:
- test
- build
- release
- review
- deploy
test:
stage: test
script:
- make test
test2:
stage: test
script:
- sleep 3
- echo "We did it! Something else runs in parallel!"
compile:
stage: build
script:
# 添加所有的依赖，或者使用 glide/govendor/...
- make build
artifacts:
paths:
- app
image_build:
stage: release
image: docker:latest
variables:
DOCKER_DRIVER: overlay
DOCKER_HOST: tcp://localhost:2375
services:
- name: docker:17.03-dind
command: ["--insecure-registry=registry.qikqiak.com"]
script:
- docker info
- docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" registry.qikqiak.com
- docker build -t "${CI_REGISTRY_IMAGE}:latest" .
- docker tag "${CI_REGISTRY_IMAGE}:latest" "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
- test ! -z "${CI_COMMIT_TAG}" && docker push "${CI_REGISTRY_IMAGE}:latest"
- docker push "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"
deploy_review:
image: cnych/kubectl
stage: review
only:
- branches
except:
- tags
environment:
name: dev
url: https://dev-gitlab-k8s-demo.qikqiak.com
on_stop: stop_review
script:
- kubectl version
- cd manifests/
- sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
- sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
- |
if kubectl apply -f deployment.yaml | grep -q unchanged; then
echo "=> Patching deployment to force image update."
kubectl patch -f deployment.yaml -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"ci-last-updated\":\"$(date +'%s')\"}}}}}"
else
echo "=> Deployment apply has changed the object, no need to force image update."
fi
- kubectl apply -f service.yaml || true
- kubectl apply -f ingress.yaml
- kubectl rollout status -f deployment.yaml
- kubectl get all,ing -l ref=${CI_ENVIRONMENT_SLUG}
stop_review:
image: cnych/kubectl
stage: review
variables:
GIT_STRATEGY: none
when: manual
only:
- branches
except:
- master
- tags
environment:
name: dev
action: stop
script:
- kubectl version
- kubectl delete ing -l ref=${CI_ENVIRONMENT_SLUG}
- kubectl delete all -l ref=${CI_ENVIRONMENT_SLUG}
deploy_live:
image: cnych/kubectl
stage: deploy
environment:
name: live
url: https://live-gitlab-k8s-demo.qikqiak.com
only:
- tags
when: manual
script:
- kubectl version
- cd manifests/
- sed -i "s/__CI_ENVIRONMENT_SLUG__/${CI_ENVIRONMENT_SLUG}/" deployment.yaml ingress.yaml service.yaml
- sed -i "s/__VERSION__/${CI_COMMIT_REF_NAME}/" deployment.yaml ingress.yaml service.yaml
- kubectl apply -f deployment.yaml
- kubectl apply -f service.yaml
- kubectl apply -f ingress.yaml
- kubectl rollout status -f deployment.yaml
- kubectl get all,ing -l ref=${CI_ENVIRONMENT_SLUG}
上面的.gitlab-ci.yml文件中还有一些特殊的属性，如限制运行的的when和only参数，例如only: ["tags"]表示只为创建的标签运行，更多的信息，我可以通过查看 Gitlab CI YAML 文件查看：https://docs.gitlab.com/ce/ci/yaml/README.html
由于我们在.gitlab-ci.yml文件中将应用的镜像构建完成后推送到了我们的私有仓库，而 Kubernetes 资源清单文件中使用的私有镜像，所以我们需要配置一个imagePullSecret，否则在 Kubernetes 集群中是无法拉取我们的私有镜像的：(替换下面相关信息为自己的)
$ kubectl create secret docker-registry myregistry --docker-server=registry.qikqiak.com --docker-username=xxxx --docker-password=xxxxxx --docker-email=xxxx -n gitlab
secret "myregistry" created
在下面的 Deployment 的资源清单文件中会使用到创建的myregistry。
接下来为应用创建 Kubernetes 资源清单文件，添加到代码仓库中。首先创建 Deployment 资源：（deployment.yaml）
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
namespace: gitlab
labels:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
track: stable
spec:
replicas: 2
selector:
matchLabels:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
template:
metadata:
labels:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
track: stable
spec:
imagePullSecrets:
- name: myregistry
containers:
- name: app
image: registry.qikqiak.com/gitdemo/gitlab-k8s:__VERSION__
imagePullPolicy: Always
ports:
- name: http-metrics
protocol: TCP
containerPort: 8000
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 3
timeoutSeconds: 2
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 3
timeoutSeconds: 2
注意用上面创建的 myregistry 替换 imagePullSecrets。
这是一个基本的 Deployment 资源清单的描述，像__CI_ENVIRONMENT_SLUG__和__VERSION__这样的占位符用于区分不同的环境，__CI_ENVIRONMENT_SLUG__将由 dev 或 live（环境名称）和__VERSION__替换为镜像标签。
为了能够连接到部署的 Pod，还需要 Service。对应的 Service 资源清单如下（service.yaml）：
---
apiVersion: v1
kind: Service
metadata:
name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
namespace: gitlab
labels:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8000"
prometheus.io/scheme: "http"
prometheus.io/path: "/metrics"
spec:
type: ClusterIP
ports:
- name: http-metrics
port: 8000
protocol: TCP
selector:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
我们的应用程序运行8000端口上，端口名为http-metrics，如果你还记得前面我们监控的课程中应该还记得我们使用prometheus-operator为 Prometheus 创建了自动发现的配置，所以我们在annotations里面配置上上面的这几个注释后，Prometheus 就可以自动获取我们应用的监控指标数据了。
现在 Service 创建成功了，但是外部用户还不能访问到我们的应用，当然我们可以把 Service 设置成 NodePort 类型，另外一个常见的方式当然就是使用 Ingress 了，我们可以通过 Ingress 来将应用暴露给外面用户使用，对应的资源清单文件如下：（ingress.yaml）
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
namespace: gitlab
labels:
app: gitlab-k8s-demo
ref: __CI_ENVIRONMENT_SLUG__
annotations:
kubernetes.io/ingress.class: "traefik"
spec:
rules:
- host: __CI_ENVIRONMENT_SLUG__-gitlab-k8s-demo.qikqiak.com
http:
paths:
- path: /
backend:
serviceName: gitlab-k8s-demo-__CI_ENVIRONMENT_SLUG__
servicePort: 8000
当然如果想配置 https 访问的话我们可以自己用 CA 证书创建一个 tls 密钥，也可以使用
cert-manager来自动为我们的应用程序添加 https。
当然要通过上面的域名进行访问，还需要进行 DNS 解析的，__CI_ENVIRONMENT_SLUG__-gitlab-k8s-demo.qikqiak.com其中__CI_ENVIRONMENT_SLUG__值为 live 或 dev，所以需要创建dev-gitlab-k8s-demo.qikqiak.com 和 live-gitlab-k8s-demo.qikqiak.com 两个域名的解析。
我们可以使用 DNS 解析服务商的 API 来自动创建域名解析，也可以使用 Kubernetes incubator 孵化的项目 external-dns operator 来进行操作。
所需要的资源清单和.gitlab-ci.yml文件已经准备好了，我们可以小小的添加一个文件去触发下 Gitlab CI 构建：
$ touch test1
$ git add .
$ git commit -m"Testing the GitLab CI functionality #1"
$ git push origin master
现在回到 Gitlab 中可以看到我们的项目触发了一个新的 Pipeline 的构建：
可以查看最后一个阶段（stage）是否正确，如果通过了，证明我们已经成功将应用程序部署到 Kubernetes 集群中了，一个成功的review阶段如下所示：
整个 Pipeline 构建成功后，我们可以在项目的环境菜单下面看到多了一个环境：
如果我们点击终止，就会调用.gitlab-ci.yml中定义的钩子on_stop: stop_review，点击View deployment就可以看到这次我们的部署结果（前提是DNS解析已经完成）：
这就是关于 Gitlab CI 结合 Kubernetes 进行 CI/CD 的过程，具体详细的构建任务还需要结合我们自己的应用实际情况而定。下节课给大家介绍使用 Jenkins + Gitlab + Harbor + Helm + Kubernetes 来实现一个完整的 CI/CD 流水线作业。